<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta http-equiv="X-UA-Compatible" content="IE=11"/>
<meta name="generator" content="Doxygen 1.9.4"/>
<meta name="viewport" content="width=device-width, initial-scale=1"/>
<title>Flow-IPC: ipc::session Namespace Reference</title>
<link href="tabs.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="dynsections.js"></script>
<link href="search/search.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="search/searchdata.js"></script>
<script type="text/javascript" src="search/search.js"></script>
<link href="doxygen.css" rel="stylesheet" type="text/css" />
</head>
<body>
<div id="top"><!-- do not remove this div, it is closed by doxygen! -->
<div id="titlearea">
<table cellspacing="0" cellpadding="0">
 <tbody>
 <tr id="projectrow">
  <td id="projectalign">
   <div id="projectname">Flow-IPC<span id="projectnumber">&#160;2.0.0</span>
   </div>
   <div id="projectbrief">Flow-IPC project: Public API.</div>
  </td>
 </tr>
 </tbody>
</table>
</div>
<!-- end header part -->
<!-- Generated by Doxygen 1.9.4 -->
<script type="text/javascript">
/* @license magnet:?xt=urn:btih:d3d9a9a6595521f9666a5e94cc830dab83b65699&amp;dn=expat.txt MIT */
var searchBox = new SearchBox("searchBox", "search",'Search','.html');
/* @license-end */
</script>
<script type="text/javascript" src="menudata.js"></script>
<script type="text/javascript" src="menu.js"></script>
<script type="text/javascript">
/* @license magnet:?xt=urn:btih:d3d9a9a6595521f9666a5e94cc830dab83b65699&amp;dn=expat.txt MIT */
$(function() {
  initMenu('',true,false,'search.php','Search');
  $(document).ready(function() { init_search(); });
});
/* @license-end */
</script>
<div id="main-nav"></div>
<!-- window showing the filter options -->
<div id="MSearchSelectWindow"
     onmouseover="return searchBox.OnSearchSelectShow()"
     onmouseout="return searchBox.OnSearchSelectHide()"
     onkeydown="return searchBox.OnSearchSelectKey(event)">
</div>

<!-- iframe showing the search results (closed by default) -->
<div id="MSearchResultsWindow">
<iframe src="javascript:void(0)" frameborder="0" 
        name="MSearchResults" id="MSearchResults">
</iframe>
</div>

<div id="nav-path" class="navpath">
  <ul>
<li class="navelem"><a class="el" href="namespaceipc.html">ipc</a></li><li class="navelem"><a class="el" href="namespaceipc_1_1session.html">session</a></li>  </ul>
</div>
</div><!-- top -->
<div class="header">
  <div class="summary">
<a href="#namespaces">Namespaces</a> &#124;
<a href="#nested-classes">Classes</a> &#124;
<a href="#typedef-members">Typedefs</a> &#124;
<a href="#func-members">Functions</a>  </div>
  <div class="headertitle"><div class="title">ipc::session Namespace Reference</div></div>
</div><!--header-->
<div class="contents">

<p>Flow-IPC module providing the broad lifecycle and shared-resource organization &ndash; via the <em>session</em> concept &ndash; in such a way as to make it possible for a given pair of processes A and B to set up <a class="el" href="namespaceipc_1_1transport.html" title="Flow-IPC module providing transmission of structured messages and/or low-level blobs (and more) betwe...">ipc::transport</a> structured- or unstructured-message channels for general IPC, as well as to share data in SHared Memory (SHM).  
<a href="namespaceipc_1_1session.html#details">More...</a></p>
<table class="memberdecls">
<tr class="heading"><td colspan="2"><h2 class="groupheader"><a id="namespaces" name="namespaces"></a>
Namespaces</h2></td></tr>
<tr class="memitem:namespaceipc_1_1session_1_1error"><td class="memItemLeft" align="right" valign="top">namespace &#160;</td><td class="memItemRight" valign="bottom"><a class="el" href="namespaceipc_1_1session_1_1error.html">error</a></td></tr>
<tr class="memdesc:namespaceipc_1_1session_1_1error"><td class="mdescLeft">&#160;</td><td class="mdescRight">Namespace containing the <a class="el" href="namespaceipc_1_1session.html" title="Flow-IPC module providing the broad lifecycle and shared-resource organization – via the session conc...">ipc::session</a> module's extension of <a class="el" href="namespaceboost_1_1system.html" title="Small group of miscellaneous utilities to ease work with boost.system, joining its boost::system name...">boost.system</a> error conventions, so that that API can return codes/messages from within its own new set of error codes/messages. <br /></td></tr>
<tr class="separator:"><td class="memSeparator" colspan="2">&#160;</td></tr>
<tr class="memitem:namespaceipc_1_1session_1_1shm"><td class="memItemLeft" align="right" valign="top">namespace &#160;</td><td class="memItemRight" valign="bottom"><a class="el" href="namespaceipc_1_1session_1_1shm.html">shm</a></td></tr>
<tr class="memdesc:namespaceipc_1_1session_1_1shm"><td class="mdescLeft">&#160;</td><td class="mdescRight"><a class="el" href="namespaceipc_1_1session.html" title="Flow-IPC module providing the broad lifecycle and shared-resource organization – via the session conc...">ipc::session</a> sub-namespace that groups together facilities for SHM-backed sessions, particularly augmenting <a class="el" href="namespaceipc_1_1session.html#a77d8fda00e1e17f595a6a5d4c44375e7" title="A vanilla Client_session with no optional capabilities.">Client_session</a>, <a class="el" href="namespaceipc_1_1session.html#ab01d5bce0ab2f3435ca9dd88d27609dc" title="A vanilla Server_session with no optional capabilities.">Server_session</a>, and <a class="el" href="classipc_1_1session_1_1Session__server.html" title="To be instantiated typically once in a given process, an object of this type asynchronously listens f...">Session_server</a> classes by providing SHM-backed zero-copy functionality. <br /></td></tr>
<tr class="separator:"><td class="memSeparator" colspan="2">&#160;</td></tr>
<tr class="memitem:namespaceipc_1_1session_1_1sync__io"><td class="memItemLeft" align="right" valign="top">namespace &#160;</td><td class="memItemRight" valign="bottom"><a class="el" href="namespaceipc_1_1session_1_1sync__io.html">sync_io</a></td></tr>
<tr class="memdesc:namespaceipc_1_1session_1_1sync__io"><td class="mdescLeft">&#160;</td><td class="mdescRight"><code><a class="el" href="namespaceipc_1_1session_1_1sync__io.html" title="sync_io-pattern counterparts to async-I/O-pattern object types in parent namespace ipc::session.">sync_io</a></code>-pattern counterparts to async-I/O-pattern object types in parent namespace <a class="el" href="namespaceipc_1_1session.html" title="Flow-IPC module providing the broad lifecycle and shared-resource organization – via the session conc...">ipc::session</a>. <br /></td></tr>
<tr class="separator:"><td class="memSeparator" colspan="2">&#160;</td></tr>
</table><table class="memberdecls">
<tr class="heading"><td colspan="2"><h2 class="groupheader"><a id="nested-classes" name="nested-classes"></a>
Classes</h2></td></tr>
<tr class="memitem:"><td class="memItemLeft" align="right" valign="top">struct &#160;</td><td class="memItemRight" valign="bottom"><a class="el" href="structipc_1_1session_1_1App.html">App</a></td></tr>
<tr class="memdesc:"><td class="mdescLeft">&#160;</td><td class="mdescRight">A <em>description</em> of an application in this <a class="el" href="namespaceipc_1_1session.html" title="Flow-IPC module providing the broad lifecycle and shared-resource organization – via the session conc...">ipc::session</a> inter-process communication universe.  <a href="structipc_1_1session_1_1App.html#details">More...</a><br /></td></tr>
<tr class="separator:"><td class="memSeparator" colspan="2">&#160;</td></tr>
<tr class="memitem:"><td class="memItemLeft" align="right" valign="top">struct &#160;</td><td class="memItemRight" valign="bottom"><a class="el" href="structipc_1_1session_1_1Client__app.html">Client_app</a></td></tr>
<tr class="memdesc:"><td class="mdescLeft">&#160;</td><td class="mdescRight">An <a class="el" href="structipc_1_1session_1_1App.html" title="A description of an application in this ipc::session inter-process communication universe.">App</a> that is used as a client in at least one client-server IPC split.  <a href="structipc_1_1session_1_1Client__app.html#details">More...</a><br /></td></tr>
<tr class="separator:"><td class="memSeparator" colspan="2">&#160;</td></tr>
<tr class="memitem:"><td class="memItemLeft" align="right" valign="top">class &#160;</td><td class="memItemRight" valign="bottom"><a class="el" href="classipc_1_1session_1_1Client__session__mv.html">Client_session_mv</a></td></tr>
<tr class="memdesc:"><td class="mdescLeft">&#160;</td><td class="mdescRight">Implements <a class="el" href="classipc_1_1session_1_1Session.html" title="A documentation-only concept defining the local side of an IPC conversation (session) with another en...">Session</a> concept on the <a class="el" href="structipc_1_1session_1_1Client__app.html" title="An App that is used as a client in at least one client-server IPC split.">Client_app</a> end: a <a class="el" href="classipc_1_1session_1_1Session__mv.html" title="Implements the Session concept when it is in PEER state.">Session_mv</a> that first achieves PEER state by connecting to an opposing <a class="el" href="classipc_1_1session_1_1Session__server.html" title="To be instantiated typically once in a given process, an object of this type asynchronously listens f...">Session_server</a> via <a class="el" href="classipc_1_1session_1_1Client__session__mv.html#ab971ea979200828d572638c60d7d9f44" title="To be invoked in NULL state only, and not as-if default-cted, it synchronously and non-blockingly att...">Client_session_mv::sync_connect()</a>.  <a href="classipc_1_1session_1_1Client__session__mv.html#details">More...</a><br /></td></tr>
<tr class="separator:"><td class="memSeparator" colspan="2">&#160;</td></tr>
<tr class="memitem:"><td class="memItemLeft" align="right" valign="top">struct &#160;</td><td class="memItemRight" valign="bottom"><a class="el" href="structipc_1_1session_1_1Server__app.html">Server_app</a></td></tr>
<tr class="memdesc:"><td class="mdescLeft">&#160;</td><td class="mdescRight">An <a class="el" href="structipc_1_1session_1_1App.html" title="A description of an application in this ipc::session inter-process communication universe.">App</a> that is used as a server in at least one client-server IPC split.  <a href="structipc_1_1session_1_1Server__app.html#details">More...</a><br /></td></tr>
<tr class="separator:"><td class="memSeparator" colspan="2">&#160;</td></tr>
<tr class="memitem:"><td class="memItemLeft" align="right" valign="top">class &#160;</td><td class="memItemRight" valign="bottom"><a class="el" href="classipc_1_1session_1_1Server__session__mv.html">Server_session_mv</a></td></tr>
<tr class="memdesc:"><td class="mdescLeft">&#160;</td><td class="mdescRight">Implements <a class="el" href="classipc_1_1session_1_1Session.html" title="A documentation-only concept defining the local side of an IPC conversation (session) with another en...">Session</a> concept on the <a class="el" href="structipc_1_1session_1_1Server__app.html" title="An App that is used as a server in at least one client-server IPC split.">Server_app</a> end: a <a class="el" href="classipc_1_1session_1_1Session.html" title="A documentation-only concept defining the local side of an IPC conversation (session) with another en...">Session</a> that is emitted in almost-PEER state by local <a class="el" href="classipc_1_1session_1_1Session__server.html" title="To be instantiated typically once in a given process, an object of this type asynchronously listens f...">Session_server</a> accepting a connection by an opposing <code><a class="el" href="classipc_1_1session_1_1Client__session__mv.html#ab971ea979200828d572638c60d7d9f44" title="To be invoked in NULL state only, and not as-if default-cted, it synchronously and non-blockingly att...">Client_session_mv::sync_connect()</a></code>.  <a href="classipc_1_1session_1_1Server__session__mv.html#details">More...</a><br /></td></tr>
<tr class="separator:"><td class="memSeparator" colspan="2">&#160;</td></tr>
<tr class="memitem:"><td class="memItemLeft" align="right" valign="top">class &#160;</td><td class="memItemRight" valign="bottom"><a class="el" href="classipc_1_1session_1_1Session.html">Session</a></td></tr>
<tr class="memdesc:"><td class="mdescLeft">&#160;</td><td class="mdescRight">A documentation-only <em>concept</em> defining the local side of an IPC conversation (<em>session</em>) with another entity (typically a separate process), also represented by a Session-implementing object, through which one can easily open IPC channels (<a class="el" href="classipc_1_1transport_1_1Channel.html" title="Peer to a bundle of 1-2 full-duplex pipe(s), one for transmitting unstructured binary blobs; the othe...">ipc::transport::Channel</a>), among other IPC features.  <a href="classipc_1_1session_1_1Session.html#details">More...</a><br /></td></tr>
<tr class="separator:"><td class="memSeparator" colspan="2">&#160;</td></tr>
<tr class="memitem:"><td class="memItemLeft" align="right" valign="top">class &#160;</td><td class="memItemRight" valign="bottom"><a class="el" href="classipc_1_1session_1_1Session__mv.html">Session_mv</a></td></tr>
<tr class="memdesc:"><td class="mdescLeft">&#160;</td><td class="mdescRight">Implements the <a class="el" href="classipc_1_1session_1_1Session.html" title="A documentation-only concept defining the local side of an IPC conversation (session) with another en...">Session</a> concept when it is in PEER state.  <a href="classipc_1_1session_1_1Session__mv.html#details">More...</a><br /></td></tr>
<tr class="separator:"><td class="memSeparator" colspan="2">&#160;</td></tr>
<tr class="memitem:"><td class="memItemLeft" align="right" valign="top">class &#160;</td><td class="memItemRight" valign="bottom"><a class="el" href="classipc_1_1session_1_1Session__server.html">Session_server</a></td></tr>
<tr class="memdesc:"><td class="mdescLeft">&#160;</td><td class="mdescRight">To be instantiated typically once in a given process, an object of this type asynchronously listens for <a class="el" href="structipc_1_1session_1_1Client__app.html" title="An App that is used as a client in at least one client-server IPC split.">Client_app</a> processes each of which wishes to establish a <em>session</em> with this server process; emits resulting Server_session objects locally.  <a href="classipc_1_1session_1_1Session__server.html#details">More...</a><br /></td></tr>
<tr class="separator:"><td class="memSeparator" colspan="2">&#160;</td></tr>
</table><table class="memberdecls">
<tr class="heading"><td colspan="2"><h2 class="groupheader"><a id="typedef-members" name="typedef-members"></a>
Typedefs</h2></td></tr>
<tr class="memitem:a6d07d9996af19e57eb42416e914110ea"><td class="memItemLeft" align="right" valign="top"><a id="a6d07d9996af19e57eb42416e914110ea" name="a6d07d9996af19e57eb42416e914110ea"></a>
using&#160;</td><td class="memItemRight" valign="bottom"><b>Shared_name</b> = <a class="el" href="classipc_1_1util_1_1Shared__name.html">util::Shared_name</a></td></tr>
<tr class="memdesc:a6d07d9996af19e57eb42416e914110ea"><td class="mdescLeft">&#160;</td><td class="mdescRight">Convenience alias for the commonly used type <a class="el" href="classipc_1_1util_1_1Shared__name.html" title="String-wrapping abstraction representing a name uniquely distinguishing a kernel-persistent entity fr...">util::Shared_name</a>. <br /></td></tr>
<tr class="separator:a6d07d9996af19e57eb42416e914110ea"><td class="memSeparator" colspan="2">&#160;</td></tr>
<tr class="memitem:ade2b302f1a3623e8adc9694568d94d2c"><td class="memItemLeft" align="right" valign="top"><a id="ade2b302f1a3623e8adc9694568d94d2c" name="ade2b302f1a3623e8adc9694568d94d2c"></a>
using&#160;</td><td class="memItemRight" valign="bottom"><b>Session_token</b> = <a class="el" href="namespaceipc_1_1transport_1_1struc.html#a6751c05fb6582a34c7c47ac470c4a48b">transport::struc::Session_token</a></td></tr>
<tr class="memdesc:ade2b302f1a3623e8adc9694568d94d2c"><td class="mdescLeft">&#160;</td><td class="mdescRight">Convenience alias for the commonly used type <a class="el" href="namespaceipc_1_1transport_1_1struc.html#a6751c05fb6582a34c7c47ac470c4a48b" title="A type used by struc::Channel for internal safety/security/auth needs.">transport::struc::Session_token</a>. <br /></td></tr>
<tr class="separator:ade2b302f1a3623e8adc9694568d94d2c"><td class="memSeparator" colspan="2">&#160;</td></tr>
<tr class="memitem:ab01d5bce0ab2f3435ca9dd88d27609dc"><td class="memTemplParams" colspan="2">template&lt;schema::MqType S_MQ_TYPE_OR_NONE, bool S_TRANSMIT_NATIVE_HANDLES, typename Mdt_payload  = ::capnp::Void&gt; </td></tr>
<tr class="memitem:ab01d5bce0ab2f3435ca9dd88d27609dc"><td class="memTemplItemLeft" align="right" valign="top">using&#160;</td><td class="memTemplItemRight" valign="bottom"><a class="el" href="namespaceipc_1_1session.html#ab01d5bce0ab2f3435ca9dd88d27609dc">Server_session</a> = <a class="el" href="classipc_1_1session_1_1Server__session__mv.html">Server_session_mv</a>&lt; Server_session_impl&lt; S_MQ_TYPE_OR_NONE, S_TRANSMIT_NATIVE_HANDLES, Mdt_payload &gt; &gt;</td></tr>
<tr class="memdesc:ab01d5bce0ab2f3435ca9dd88d27609dc"><td class="mdescLeft">&#160;</td><td class="mdescRight">A vanilla <code>Server_session</code> with no optional capabilities.  <a href="namespaceipc_1_1session.html#ab01d5bce0ab2f3435ca9dd88d27609dc">More...</a><br /></td></tr>
<tr class="separator:ab01d5bce0ab2f3435ca9dd88d27609dc"><td class="memSeparator" colspan="2">&#160;</td></tr>
<tr class="memitem:a77d8fda00e1e17f595a6a5d4c44375e7"><td class="memTemplParams" colspan="2">template&lt;schema::MqType S_MQ_TYPE_OR_NONE, bool S_TRANSMIT_NATIVE_HANDLES, typename Mdt_payload  = ::capnp::Void&gt; </td></tr>
<tr class="memitem:a77d8fda00e1e17f595a6a5d4c44375e7"><td class="memTemplItemLeft" align="right" valign="top">using&#160;</td><td class="memTemplItemRight" valign="bottom"><a class="el" href="namespaceipc_1_1session.html#a77d8fda00e1e17f595a6a5d4c44375e7">Client_session</a> = <a class="el" href="classipc_1_1session_1_1Client__session__mv.html">Client_session_mv</a>&lt; Client_session_impl&lt; S_MQ_TYPE_OR_NONE, S_TRANSMIT_NATIVE_HANDLES, Mdt_payload &gt; &gt;</td></tr>
<tr class="memdesc:a77d8fda00e1e17f595a6a5d4c44375e7"><td class="mdescLeft">&#160;</td><td class="mdescRight">A vanilla <code>Client_session</code> with no optional capabilities.  <a href="namespaceipc_1_1session.html#a77d8fda00e1e17f595a6a5d4c44375e7">More...</a><br /></td></tr>
<tr class="separator:a77d8fda00e1e17f595a6a5d4c44375e7"><td class="memSeparator" colspan="2">&#160;</td></tr>
</table><table class="memberdecls">
<tr class="heading"><td colspan="2"><h2 class="groupheader"><a id="func-members" name="func-members"></a>
Functions</h2></td></tr>
<tr class="memitem:a0eac87b284d50832334d819a8877cbaa"><td class="memItemLeft" align="right" valign="top">void&#160;</td><td class="memItemRight" valign="bottom"><a class="el" href="namespaceipc_1_1session.html#a0eac87b284d50832334d819a8877cbaa">ensure_resource_owner_is_app</a> (flow::log::Logger *logger_ptr, const fs::path &amp;path, const <a class="el" href="structipc_1_1session_1_1App.html">App</a> &amp;app, <a class="el" href="namespaceipc.html#aa3192e586cc45d3e7c22463bf2760f89">Error_code</a> *err_code=0)</td></tr>
<tr class="memdesc:a0eac87b284d50832334d819a8877cbaa"><td class="mdescLeft">&#160;</td><td class="mdescRight">Utility, used internally but exposed in public API in case it is of general use, that checks that the owner of the given resource (at the supplied file system path) is as specified in the given <a class="el" href="structipc_1_1session_1_1App.html" title="A description of an application in this ipc::session inter-process communication universe.">App</a> (<a class="el" href="structipc_1_1session_1_1App.html#a9e32297579603f2d96616976474d0246" title="The application must run as this user ID (UID). Files and other shared resources shall have this owne...">App::m_user_id</a> et al).  <a href="namespaceipc_1_1session.html#a0eac87b284d50832334d819a8877cbaa">More...</a><br /></td></tr>
<tr class="separator:a0eac87b284d50832334d819a8877cbaa"><td class="memSeparator" colspan="2">&#160;</td></tr>
<tr class="memitem:ac7f0052fa0537c3696063693644bcff8"><td class="memItemLeft" align="right" valign="top">void&#160;</td><td class="memItemRight" valign="bottom"><a class="el" href="namespaceipc_1_1session.html#ac7f0052fa0537c3696063693644bcff8">ensure_resource_owner_is_app</a> (flow::log::Logger *logger_ptr, <a class="el" href="structipc_1_1util_1_1Native__handle.html">util::Native_handle</a> handle, const <a class="el" href="structipc_1_1session_1_1App.html">App</a> &amp;app, <a class="el" href="namespaceipc.html#aa3192e586cc45d3e7c22463bf2760f89">Error_code</a> *err_code=0)</td></tr>
<tr class="memdesc:ac7f0052fa0537c3696063693644bcff8"><td class="mdescLeft">&#160;</td><td class="mdescRight">Identical to the other <a class="el" href="namespaceipc_1_1session.html#a0eac87b284d50832334d819a8877cbaa" title="Utility, used internally but exposed in public API in case it is of general use, that checks that the...">ensure_resource_owner_is_app()</a> overload but operates on a pre-opened <code>Native_handle</code> (a/k/a handle, socket, file descriptor) to the resource in question.  <a href="namespaceipc_1_1session.html#ac7f0052fa0537c3696063693644bcff8">More...</a><br /></td></tr>
<tr class="separator:ac7f0052fa0537c3696063693644bcff8"><td class="memSeparator" colspan="2">&#160;</td></tr>
<tr class="memitem:a6b2f9a90ac9cc5098d9b90e7f547c97e"><td class="memItemLeft" align="right" valign="top">std::ostream &amp;&#160;</td><td class="memItemRight" valign="bottom"><a class="el" href="namespaceipc_1_1session.html#a6b2f9a90ac9cc5098d9b90e7f547c97e">operator&lt;&lt;</a> (std::ostream &amp;os, const <a class="el" href="structipc_1_1session_1_1App.html">App</a> &amp;val)</td></tr>
<tr class="memdesc:a6b2f9a90ac9cc5098d9b90e7f547c97e"><td class="mdescLeft">&#160;</td><td class="mdescRight">Prints string representation of the given <code><a class="el" href="structipc_1_1session_1_1App.html" title="A description of an application in this ipc::session inter-process communication universe.">App</a></code> to the given <code>ostream</code>.  <a href="namespaceipc_1_1session.html#a6b2f9a90ac9cc5098d9b90e7f547c97e">More...</a><br /></td></tr>
<tr class="separator:a6b2f9a90ac9cc5098d9b90e7f547c97e"><td class="memSeparator" colspan="2">&#160;</td></tr>
<tr class="memitem:a0e786447d51449f1249c10e127ab10e2"><td class="memItemLeft" align="right" valign="top">std::ostream &amp;&#160;</td><td class="memItemRight" valign="bottom"><a class="el" href="namespaceipc_1_1session.html#a0e786447d51449f1249c10e127ab10e2">operator&lt;&lt;</a> (std::ostream &amp;os, const <a class="el" href="structipc_1_1session_1_1Client__app.html">Client_app</a> &amp;val)</td></tr>
<tr class="memdesc:a0e786447d51449f1249c10e127ab10e2"><td class="mdescLeft">&#160;</td><td class="mdescRight">Prints string representation of the given <code>Client_appp</code> to the given <code>ostream</code>.  <a href="namespaceipc_1_1session.html#a0e786447d51449f1249c10e127ab10e2">More...</a><br /></td></tr>
<tr class="separator:a0e786447d51449f1249c10e127ab10e2"><td class="memSeparator" colspan="2">&#160;</td></tr>
<tr class="memitem:a34a03a25908100446b3eca2e8dca61fe"><td class="memItemLeft" align="right" valign="top">std::ostream &amp;&#160;</td><td class="memItemRight" valign="bottom"><a class="el" href="namespaceipc_1_1session.html#a34a03a25908100446b3eca2e8dca61fe">operator&lt;&lt;</a> (std::ostream &amp;os, const <a class="el" href="structipc_1_1session_1_1Server__app.html">Server_app</a> &amp;val)</td></tr>
<tr class="memdesc:a34a03a25908100446b3eca2e8dca61fe"><td class="mdescLeft">&#160;</td><td class="mdescRight">Prints string representation of the given <code><a class="el" href="structipc_1_1session_1_1Server__app.html" title="An App that is used as a server in at least one client-server IPC split.">Server_app</a></code> to the given <code>ostream</code>.  <a href="namespaceipc_1_1session.html#a34a03a25908100446b3eca2e8dca61fe">More...</a><br /></td></tr>
<tr class="separator:a34a03a25908100446b3eca2e8dca61fe"><td class="memSeparator" colspan="2">&#160;</td></tr>
<tr class="memitem:a8a2e780e6c5266b8c2e4207d7e256afe"><td class="memTemplParams" colspan="2">template&lt;typename Client_session_impl_t &gt; </td></tr>
<tr class="memitem:a8a2e780e6c5266b8c2e4207d7e256afe"><td class="memTemplItemLeft" align="right" valign="top">std::ostream &amp;&#160;</td><td class="memTemplItemRight" valign="bottom"><a class="el" href="namespaceipc_1_1session.html#a8a2e780e6c5266b8c2e4207d7e256afe">operator&lt;&lt;</a> (std::ostream &amp;os, const <a class="el" href="classipc_1_1session_1_1Client__session__mv.html">Client_session_mv</a>&lt; Client_session_impl_t &gt; &amp;val)</td></tr>
<tr class="memdesc:a8a2e780e6c5266b8c2e4207d7e256afe"><td class="mdescLeft">&#160;</td><td class="mdescRight">Prints string representation of the given <code><a class="el" href="classipc_1_1session_1_1Client__session__mv.html" title="Implements Session concept on the Client_app end: a Session_mv that first achieves PEER state by conn...">Client_session_mv</a></code> to the given <code>ostream</code>.  <a href="namespaceipc_1_1session.html#a8a2e780e6c5266b8c2e4207d7e256afe">More...</a><br /></td></tr>
<tr class="separator:a8a2e780e6c5266b8c2e4207d7e256afe"><td class="memSeparator" colspan="2">&#160;</td></tr>
<tr class="memitem:aed5397fd025606507ad8dab74479762f"><td class="memTemplParams" colspan="2">template&lt;typename Server_session_impl_t &gt; </td></tr>
<tr class="memitem:aed5397fd025606507ad8dab74479762f"><td class="memTemplItemLeft" align="right" valign="top">std::ostream &amp;&#160;</td><td class="memTemplItemRight" valign="bottom"><a class="el" href="namespaceipc_1_1session.html#aed5397fd025606507ad8dab74479762f">operator&lt;&lt;</a> (std::ostream &amp;os, const <a class="el" href="classipc_1_1session_1_1Server__session__mv.html">Server_session_mv</a>&lt; Server_session_impl_t &gt; &amp;val)</td></tr>
<tr class="memdesc:aed5397fd025606507ad8dab74479762f"><td class="mdescLeft">&#160;</td><td class="mdescRight">Prints string representation of the given <code><a class="el" href="classipc_1_1session_1_1Server__session__mv.html" title="Implements Session concept on the Server_app end: a Session that is emitted in almost-PEER state by l...">Server_session_mv</a></code> to the given <code>ostream</code>.  <a href="namespaceipc_1_1session.html#aed5397fd025606507ad8dab74479762f">More...</a><br /></td></tr>
<tr class="separator:aed5397fd025606507ad8dab74479762f"><td class="memSeparator" colspan="2">&#160;</td></tr>
<tr class="memitem:a07c2d7a228f070e32bf4f1fbc64e1f6d"><td class="memTemplParams" colspan="2">template&lt;typename Session_impl_t &gt; </td></tr>
<tr class="memitem:a07c2d7a228f070e32bf4f1fbc64e1f6d"><td class="memTemplItemLeft" align="right" valign="top">std::ostream &amp;&#160;</td><td class="memTemplItemRight" valign="bottom"><a class="el" href="namespaceipc_1_1session.html#a07c2d7a228f070e32bf4f1fbc64e1f6d">operator&lt;&lt;</a> (std::ostream &amp;os, const <a class="el" href="classipc_1_1session_1_1Session__mv.html">Session_mv</a>&lt; Session_impl_t &gt; &amp;val)</td></tr>
<tr class="memdesc:a07c2d7a228f070e32bf4f1fbc64e1f6d"><td class="mdescLeft">&#160;</td><td class="mdescRight">Prints string representation of the given <code><a class="el" href="classipc_1_1session_1_1Session__mv.html" title="Implements the Session concept when it is in PEER state.">Session_mv</a></code> to the given <code>ostream</code>.  <a href="namespaceipc_1_1session.html#a07c2d7a228f070e32bf4f1fbc64e1f6d">More...</a><br /></td></tr>
<tr class="separator:a07c2d7a228f070e32bf4f1fbc64e1f6d"><td class="memSeparator" colspan="2">&#160;</td></tr>
<tr class="memitem:addd131b7a844d2a22a7436ed0c8597bc"><td class="memTemplParams" colspan="2">template&lt;schema::MqType S_MQ_TYPE_OR_NONE, bool S_TRANSMIT_NATIVE_HANDLES, typename Mdt_payload &gt; </td></tr>
<tr class="memitem:addd131b7a844d2a22a7436ed0c8597bc"><td class="memTemplItemLeft" align="right" valign="top">std::ostream &amp;&#160;</td><td class="memTemplItemRight" valign="bottom"><a class="el" href="namespaceipc_1_1session.html#addd131b7a844d2a22a7436ed0c8597bc">operator&lt;&lt;</a> (std::ostream &amp;os, const <a class="el" href="classipc_1_1session_1_1Session__server.html">Session_server</a>&lt; S_MQ_TYPE_OR_NONE, S_TRANSMIT_NATIVE_HANDLES, Mdt_payload &gt; &amp;val)</td></tr>
<tr class="memdesc:addd131b7a844d2a22a7436ed0c8597bc"><td class="mdescLeft">&#160;</td><td class="mdescRight">Prints string representation of the given <code><a class="el" href="classipc_1_1session_1_1Session__server.html" title="To be instantiated typically once in a given process, an object of this type asynchronously listens f...">Session_server</a></code> to the given <code>ostream</code>.  <a href="namespaceipc_1_1session.html#addd131b7a844d2a22a7436ed0c8597bc">More...</a><br /></td></tr>
<tr class="separator:addd131b7a844d2a22a7436ed0c8597bc"><td class="memSeparator" colspan="2">&#160;</td></tr>
</table>
<a name="details" id="details"></a><h2 class="groupheader">Detailed Description</h2>
<div class="textblock"><p >Flow-IPC module providing the broad lifecycle and shared-resource organization &ndash; via the <em>session</em> concept &ndash; in such a way as to make it possible for a given pair of processes A and B to set up <a class="el" href="namespaceipc_1_1transport.html" title="Flow-IPC module providing transmission of structured messages and/or low-level blobs (and more) betwe...">ipc::transport</a> structured- or unstructured-message channels for general IPC, as well as to share data in SHared Memory (SHM). </p>
<p >See namespace <a class="el" href="namespaceipc.html" title="Catch-all namespace for the Flow-IPC project: A library/API in modern C++17 providing high-performanc...">ipc</a> doc header for an overview of Flow-IPC modules including how <a class="el" href="namespaceipc_1_1session.html" title="Flow-IPC module providing the broad lifecycle and shared-resource organization – via the session conc...">ipc::session</a> relates to the others. Then return here. A synopsis follows:</p>
<p >It is possible to use the structured layer of <a class="el" href="namespaceipc_1_1transport.html" title="Flow-IPC module providing transmission of structured messages and/or low-level blobs (and more) betwe...">ipc::transport</a>, namely the big daddy <a class="el" href="classipc_1_1transport_1_1struc_1_1Channel.html" title="Owning and wrapping a pre-connected transport::Channel peer (an endpoint of an established channel ov...">transport::struc::Channel</a>, without any help from <a class="el" href="namespaceipc_1_1session.html" title="Flow-IPC module providing the broad lifecycle and shared-resource organization – via the session conc...">ipc::session</a>. (It's also possible to establish unstructured <a class="el" href="classipc_1_1transport_1_1Channel.html" title="Peer to a bundle of 1-2 full-duplex pipe(s), one for transmitting unstructured binary blobs; the othe...">transport::Channel</a> and the various lower-level IPC pipes it might comprise.) And, indeed, once a given <code>struc::Channel</code> (or <code>Channel</code>) is "up," one can and <em>should</em> simply use it to send/receive stuff. The problem that <a class="el" href="namespaceipc_1_1session.html" title="Flow-IPC module providing the broad lifecycle and shared-resource organization – via the session conc...">ipc::session</a> solves is in establishing the infrastructure that makes it simple to (1) open new <code>struc::Channel</code>s or <code>Channel</code>s or SHM areas; and (2) properly deal with process lifecycle events such as the starting and ending (gracefully or otherwise) of the local and partner process.</p>
<p >Regarding (1), in particular (just to give a taste of what one means):</p><ul>
<li>What underlying low-level transports will we even be using? MQs? Local (Unix domain) stream sockets? Both?</li>
<li>For each of those, we must connect or otherwise establish each one. In the case of MQs, say, there has to be an agreed-upon <a class="el" href="classipc_1_1util_1_1Shared__name.html" title="String-wrapping abstraction representing a name uniquely distinguishing a kernel-persistent entity fr...">util::Shared_name</a> for the MQ in each direction... so what is that name? How to prevent collisions in this name?</li>
</ul>
<p >While <a class="el" href="namespaceipc_1_1transport.html" title="Flow-IPC module providing transmission of structured messages and/or low-level blobs (and more) betwe...">ipc::transport</a> lets one do whatever one wants, with great flexibility, <a class="el" href="namespaceipc_1_1session.html" title="Flow-IPC module providing the broad lifecycle and shared-resource organization – via the session conc...">ipc::session</a> establishes conventions for all these things &ndash; typically hiding/encapsulating them away.</p>
<p >Regarding (2) (again, just giving a taste):</p><ul>
<li>To what process are we even talking? What if we want to talk to 2, or 3, processes? What if we want to talk to 1+ processes of application X and 1+ processes of application Y? How might we segregate the data between these?</li>
<li>What happens if 1 of 5 instances of application X, to whom we're speaking, goes down? How to ensure cleanup of any kernel-persistence resources, such as the potentially used POSIX MQs, or even of SHM (<a class="el" href="namespaceipc_1_1shm.html" title="Modules for SHared Memory (SHM) support.">ipc::shm</a>)?</li>
</ul>
<p >Again &ndash; <a class="el" href="namespaceipc_1_1session.html" title="Flow-IPC module providing the broad lifecycle and shared-resource organization – via the session conc...">ipc::session</a> establishes conventions for these lifecycle matters and provides key utilities such as kernel-persistent resource cleanup.</p>
<h3>Basic concepts</h3>
<p >An <em>application</em> is, at least roughly speaking, 1-1 with a distinct executable presumably interested in communicating with another such executable. A <em>process</em> is a/k/a <em>instance</em> of an application that has begun execution at some point. In the IPC <em>universe</em> that uses <a class="el" href="namespaceipc.html" title="Catch-all namespace for the Flow-IPC project: A library/API in modern C++17 providing high-performanc...">ipc</a>, on a given machine, there is some number of distinct applications. If two processes A and B want to engage in IPC, then their apps A and B comprise a meta-application <em>split</em>, in that (in a sense) they are one meta-application that have been split into two.</p>
<p >A process that is actively operating, at least in the IPC sense, is called an <em>active</em> process. A zombie process in particular is not active, nor is one that has not yet initialized IPC or has shut it down, typically during graceful (or otherwise) termination.</p>
<p >In the <a class="el" href="namespaceipc_1_1session.html" title="Flow-IPC module providing the broad lifecycle and shared-resource organization – via the session conc...">ipc::session</a> model, any two processes A-B must establish a <em>session</em> before engaging in IPC. This <em>session</em> comprises all <em>shared resources</em> pertaining to those two <em>processes</em> engaging in IPC. (Spoiler alert: at a high level these resources comprise, at least, <em>channels</em> of communication &ndash; see <a class="el" href="classipc_1_1transport_1_1Channel.html" title="Peer to a bundle of 1-2 full-duplex pipe(s), one for transmitting unstructured binary blobs; the othe...">transport::Channel</a> &ndash; between them; and may also optionally comprise SHared Memory (SHM).) The session ends when either A terminates or B terminates (gracefully or otherwise), and no earlier. The session begins at roughly the earliest time when <em>both</em> A and B are active simultaneously. (It is possible either process may run before IPC and after IPC, but for purposes of our discussion we'll ignore such phases are irrelevant for simplicity of exposition.) An important set of shared resources is therefore <em>per-session shared resources</em>. (However, as we're about to explain, it is not the only type.)</p>
<p >In the <a class="el" href="namespaceipc_1_1session.html" title="Flow-IPC module providing the broad lifecycle and shared-resource organization – via the session conc...">ipc::session</a> model, in a given A-B split, one must be chosen as the <em>client</em>, the other as the <em>server</em>; let's by convention here assume they're always listed in server-client order. The decision must be made which one is which, at compile time. The decision as to which is which is an important one, when using <a class="el" href="namespaceipc_1_1session.html" title="Flow-IPC module providing the broad lifecycle and shared-resource organization – via the session conc...">ipc::session</a> and IPC in that model. While a complete discussion of making that decision is outside the scope here, the main points are that in the A-B split (A the server, B the client):</p><ul>
<li>For each <em>process</em> pair A-B, there are per-session shared resources, as described above, and as pertains to these per-session resources A is no different from B. Once either terminates, these resources are not usable and shall be cleaned up as soon as possible to free RAM/etc.</li>
<li>There may be multiple (active) instances of B at a given time but only one (active) instance of A.</li>
<li>Accordingly, A is special in that it may maintain some <em>per-app shared resources</em> (cf. per-session ones) which persist even when a given B <em>process</em> terminates (thus that A-B session ends) and are available for access both by<ul>
<li>other concurrently active instances of B; and</li>
<li>any future active instances of B.</li>
</ul>
</li>
</ul>
<p >More specifically/practically:</p><ul>
<li><em>Channels</em> are between the 2 processes A-B in session A-B. If B1 and B2 are instances of (client) app Bp, a channel cannot be established between B1 and B2; only A-B1 and A-B2. So channels are always <em>per-session</em>.</li>
<li>A <em>SHM area</em> may exist in the <em>per-session</em> scope. Hence A-B1 have a per-session SHM area; and A-B2 have a per-session SHM area. When the session ends, that SHM area goes away.</li>
<li>A <em>SHM area</em> may exist in the <em>per-app</em> scope. Hence A-B* have a per-app-B SHM area, which persists throughout the lifetime of (server) process A and remains available as B1, B2, ... start and stop. It disappears once A stops. It appears when the first instance of B establishes a session with A (i.e., lazily).</li>
</ul>
<h3>Brief illustration</h3>
<p >Suppose A is a memory cache, while B is a cache reader of objects. A starts; B1 and B2 start; so sessions A-B1 and A-B2 now exist. Now each of B1, B2 might establish channel(s) and then use it/them to issue messages and receive messages back. Now A&lt;-&gt;B1 channel(s) and A&lt;-&gt;B2 channel(s) are established. No B1&lt;-&gt;B2 channel(s) can be established. (Note: <a class="el" href="classipc_1_1transport_1_1Channel.html" title="Peer to a bundle of 1-2 full-duplex pipe(s), one for transmitting unstructured binary blobs; the othe...">transport::Channel</a> and other <a class="el" href="namespaceipc_1_1transport.html" title="Flow-IPC module providing transmission of structured messages and/or low-level blobs (and more) betwe...">ipc::transport</a> IPC techniques are &ndash; in and of themselves &ndash; session-unaware. So B1 could speak to B2. They just cannot use <a class="el" href="namespaceipc_1_1session.html" title="Flow-IPC module providing the broad lifecycle and shared-resource organization – via the session conc...">ipc::session</a> to do so. <a class="el" href="namespaceipc_1_1session.html" title="Flow-IPC module providing the broad lifecycle and shared-resource organization – via the session conc...">ipc::session</a> facilitates establishing channels and SHM in an organized fashion, and that organization currently does not support channels between instances of the same client application. <a class="el" href="namespaceipc_1_1session.html" title="Flow-IPC module providing the broad lifecycle and shared-resource organization – via the session conc...">ipc::session</a> is not the only option for doing so.)</p>
<p >Suppose, in this illustration, that A is responsible both for acquiring network objects (on behalf of B*) and memory-caching them. Then B1 might say, via an A-B1 channel, "give me object X." A does not have it in cache yet, so it loads it from network, and saves it in the <em>per-app-B</em> SHM area and replies (via same A-B1 channel) "here is object X: use this SHM handle X'." B1 then accesses X' directly in SHM. Say B2 also says "give me object X." It is cached, so A sends it X' again. Now, say A-B1 session ends, because B1 stops. All A-B1 channels go away &ndash; they are per-session resources &ndash; and any per-session-A-B1 SHM area (which we haven't mentioned in this illustration) also goes away similarly.</p>
<p >A-B2 continues. B2 could request X again, and it would work. Say B3 now starts and requests X. Again, the per-app-B SHM area persists; A would send X' to B3 as well.</p>
<p >Now suppose A stops, due to a restart. This ends A-B2 and A-B3 sessions; and the per-app-B SHM area goes away too. Thus the server process's lifetime encompasses all shared resources in the A-B split. Processes B2 and B3 continue, but they must await for a new active A process (instance) to appear, so that they can establish new A-B2 and A-B3 sessions. In the meantime, it is IPC no-man's-land: there is no active per-app-B shared resources (SHM in our illustration) and certainly no per-session-A-B* shared resources either. Once A-B2 and A-B3 (new) sessions are established, shared resources can begin to be acquired again.</p>
<p >This illustrates that:</p><ul>
<li>A is the cache server and expected to service multiple cache clients Bs. This is asymmetric.</li>
<li>A can maintain shared resources, especially SHM, that outlive any individual B process. This is asymmetric.</li>
<li>A-B channels are relevant only to a given A-B* session. (Such per-session SHM areas can also exist.) This is symmetric between A and a given B instance.</li>
<li>No shared resources survive beyond a given cache server A process. A given client B* must be prepared to establish a new session with A when another active instance of A appears, before it can access IPC channels or SHM. In that sense a given <em>session</em> is symmetric: it begins when both A and a B* are active, and it ends when either of the 2 stops.</li>
</ul>
<h3>2+ splits co-existing</h3>
<p >The above discussion concerned a particular A-B split, in which by definition A is the server (only 1 active instance at a time), while B is the client (0+ active instances at a time).</p>
<p >Take A, in split A-B. Suppose there is app Cp also. An A-C split is also possible (as is A-D, A-E, etc.). Everything written so far applies in natural fashion. Do note, however, that the per-app scope applies to a given (client) application, not all client applications. So the per-app-B SHM area is independent of the per-app-C SHM area (both maintained by A). Once the 1st instance of B establishes a session, that SHM area is lazily created. Once the 1st instance of C does the same, that separate SHM area is lazily created. So B1, B2, ... access one per-app SHM area, while C1, C2, ... access another.</p>
<p >Now consider app K, in split K-A. Here K is the server, A is the client. This, also, is allowed, despite the fact A is server in splits A-B, A-C. However, there is a natural constraint on A: there can only be one active process of it at a time, because it is the server in at least 1 split. It can be a client to server K; but there would only ever be 1 instance of it establishing sessions against K.</p>
<p >Informally: This is not necessarily frowned upon. After all the ability to have multiple concurrently active processes of a given app is somewhat exotic in the first place. That said, very vaguely speaking, it is more flexible to design a given app to only be server in every split in which it participates.</p>
<h3>Overview of relevant APIs</h3>
<p >With the above explained, here is how the <a class="el" href="namespaceipc_1_1session.html" title="Flow-IPC module providing the broad lifecycle and shared-resource organization – via the session conc...">ipc::session</a> API operates over these various ideas.</p>
<p >The simplest items are <a class="el" href="structipc_1_1session_1_1App.html" title="A description of an application in this ipc::session inter-process communication universe.">App</a> (description of an application, which might a client or a server or both), <a class="el" href="structipc_1_1session_1_1Client__app.html" title="An App that is used as a client in at least one client-server IPC split.">Client_app</a> (description of an application in its role as a client), and <a class="el" href="structipc_1_1session_1_1Server__app.html" title="An App that is used as a server in at least one client-server IPC split.">Server_app</a> (you get the idea). See their doc headers, of course, but basically these are very simple data stores describing the basic structure of the IPC universe. Each application generally shall load the same values into its master lists of these structures. References to immutable <a class="el" href="structipc_1_1session_1_1Client__app.html" title="An App that is used as a client in at least one client-server IPC split.">Client_app</a> and <a class="el" href="structipc_1_1session_1_1Server__app.html" title="An App that is used as a server in at least one client-server IPC split.">Server_app</a> objects are passed into actual APIs having to do with the <a class="el" href="classipc_1_1session_1_1Session.html" title="A documentation-only concept defining the local side of an IPC conversation (session) with another en...">Session</a> concept, to establish who can establish sessions with whom and how. Basically they describe the allowed splits.</p>
<p >As noted at the very top, the real goal is to open channels between processes and possibly to share data in SHM between them and others. To get there for a given process pair A-B, one must establish session A-B, as described above. Having chosen which one is A (server) and which is B (client), and loaded <a class="el" href="structipc_1_1session_1_1Client__app.html" title="An App that is used as a client in at least one client-server IPC split.">Client_app</a> and <a class="el" href="structipc_1_1session_1_1Server__app.html" title="An App that is used as a server in at least one client-server IPC split.">Server_app</a> structures to that effect, it is time to manage the sessions.</p>
<p >An established session is said to be a session in PEER state and is represented on each side by an object that implements the <a class="el" href="classipc_1_1session_1_1Session.html" title="A documentation-only concept defining the local side of an IPC conversation (session) with another en...">Session</a> concept (see its important doc header). On the client side, this impl is the class template <a class="el" href="namespaceipc_1_1session.html#a77d8fda00e1e17f595a6a5d4c44375e7" title="A vanilla Client_session with no optional capabilities.">Client_session</a>. On the server side, this impl is the class template <a class="el" href="namespaceipc_1_1session.html#ab01d5bce0ab2f3435ca9dd88d27609dc" title="A vanilla Server_session with no optional capabilities.">Server_session</a>. Once each respective side has its PEER-state <a class="el" href="classipc_1_1session_1_1Session.html" title="A documentation-only concept defining the local side of an IPC conversation (session) with another en...">Session</a> impl object, opening channels and operating SHM areas on a per-session basis is well documented in the <a class="el" href="classipc_1_1session_1_1Session.html" title="A documentation-only concept defining the local side of an IPC conversation (session) with another en...">Session</a> (concept) doc header and is fully symmetrical in terms of the API.</p>
<p ><a class="el" href="namespaceipc_1_1session.html#a77d8fda00e1e17f595a6a5d4c44375e7" title="A vanilla Client_session with no optional capabilities.">Client_session</a> does not begin in PEER state. One constructs it in NULL state, then invokes <code><a class="el" href="classipc_1_1session_1_1Client__session__mv.html#ab971ea979200828d572638c60d7d9f44" title="To be invoked in NULL state only, and not as-if default-cted, it synchronously and non-blockingly att...">Client_session::sync_connect()</a></code> to connect to the server process if any exists; once it fires its handler successfully, the <a class="el" href="namespaceipc_1_1session.html#a77d8fda00e1e17f595a6a5d4c44375e7" title="A vanilla Client_session with no optional capabilities.">Client_session</a> is a <a class="el" href="classipc_1_1session_1_1Session.html" title="A documentation-only concept defining the local side of an IPC conversation (session) with another en...">Session</a> in PEER state. If <a class="el" href="namespaceipc_1_1session.html#a77d8fda00e1e17f595a6a5d4c44375e7" title="A vanilla Client_session with no optional capabilities.">Client_session</a>, per <a class="el" href="classipc_1_1session_1_1Session.html" title="A documentation-only concept defining the local side of an IPC conversation (session) with another en...">Session</a> concept requirements, indicates the session has finished (due to the other side ending session), one must create a new <a class="el" href="namespaceipc_1_1session.html#a77d8fda00e1e17f595a6a5d4c44375e7" title="A vanilla Client_session with no optional capabilities.">Client_session</a> and start over (w/r/t IPC and relevant shared resources).</p>
<p >Asymmetrically, on the server side, one must be ready to open potentially multiple <code>Server_session</code>s. Firstly create a <a class="el" href="classipc_1_1session_1_1Session__server.html" title="To be instantiated typically once in a given process, an object of this type asynchronously listens f...">Session_server</a> (see its doc header). To open 1 <a class="el" href="namespaceipc_1_1session.html#ab01d5bce0ab2f3435ca9dd88d27609dc" title="A vanilla Server_session with no optional capabilities.">Server_session</a>, default-construct one (hence in NULL state), then pass it as the target to <a class="el" href="classipc_1_1session_1_1Session__server.html#a13887cd64912bb5f5675e2817ff8435f" title="Asynchronously awaits for an opposing Client_session to request session establishment and calls on_do...">Session_server::async_accept()</a>. Once it fires your handler, you have an (almost-)PEER state Server_session, and moreover you may call <code><a class="el" href="classipc_1_1session_1_1Server__session__mv.html#ac873543383b7a6da94d4353231f34ec2" title="The opposing application is described by a Client_app; this is that description.">Server_session::client_app()</a></code> to determine the identity of the connecting client app (via <a class="el" href="structipc_1_1session_1_1Client__app.html" title="An App that is used as a client in at least one client-server IPC split.">Client_app</a>) which should (in multi-split situations) help decide what to further do with this Server_session (also, as on the opposing side, now a PEER-state <a class="el" href="classipc_1_1session_1_1Session.html" title="A documentation-only concept defining the local side of an IPC conversation (session) with another en...">Session</a> concept impl). (If A participates in splits A-B and A-C, then the types of IPC work it might do with a B1 or B2 is likely to be quite different from same with a C1 or C2 or C3. If only split A-B is relevant to A, then that is not a concern.)</p>
<p >As noted, in terms of per-session shared resources, most notably channel communication, a <code>Server_session</code> and <code>Client_session</code> have identical APIs with identical capabilities, each implementing the PEER-state <a class="el" href="classipc_1_1session_1_1Session.html" title="A documentation-only concept defining the local side of an IPC conversation (session) with another en...">Session</a> concept to the letter.</p>
<h3>SHM</h3>
<p >Extremely important (for performance at least) functionality is provided in the sub-namespace of <a class="el" href="namespaceipc_1_1session.html" title="Flow-IPC module providing the broad lifecycle and shared-resource organization – via the session conc...">ipc::session</a>: <a class="el" href="namespaceipc_1_1session_1_1shm.html" title="ipc::session sub-namespace that groups together facilities for SHM-backed sessions,...">ipc::session::shm</a>. Please read its doc header now before using the types directly within <a class="el" href="namespaceipc_1_1session.html" title="Flow-IPC module providing the broad lifecycle and shared-resource organization – via the session conc...">ipc::session</a>. That will allow you to make an informed choice.</p>
<h3><code><a class="el" href="namespaceipc_1_1session_1_1sync__io.html" title="sync_io-pattern counterparts to async-I/O-pattern object types in parent namespace ipc::session.">sync_io</a></code>: integrate with <code>poll()</code>-ish event loops</h3>
<p ><a class="el" href="namespaceipc_1_1session.html" title="Flow-IPC module providing the broad lifecycle and shared-resource organization – via the session conc...">ipc::session</a> APIs feature exactly the following asynchronous (blocking, background, not-non-blocking, long...) operations:</p><ul>
<li><a class="el" href="classipc_1_1session_1_1Session.html" title="A documentation-only concept defining the local side of an IPC conversation (session) with another en...">ipc::session::Session</a> on-error and (optionally) on-passive-channel-open handlers.</li>
<li><code>ipc::session::Client_session::async_connect()</code> (same for other, including SHM-aware, variants).</li>
<li><a class="el" href="classipc_1_1session_1_1Session__server.html#a13887cd64912bb5f5675e2817ff8435f" title="Asynchronously awaits for an opposing Client_session to request session establishment and calls on_do...">ipc::session::Session_server::async_accept()</a> (same for SHM-aware variants).</li>
</ul>
<p >All APIs mentioned so far operation broadly in the async-I/O pattern: Each event in question is reported from some unspecified background thread; it is up to the user to "post" the true handling onto their worker thread(s) as desired.</p>
<p >If one desires to be informed, instead, in a fashion friendly to old-school reactor loops &ndash; centered on <code>poll()</code>, <code>epoll_wait()</code>, or similar &ndash; a <code><a class="el" href="namespaceipc_1_1session_1_1sync__io.html" title="sync_io-pattern counterparts to async-I/O-pattern object types in parent namespace ipc::session.">sync_io</a></code> alternate API is available. It is no faster, but it may be more convenient for some applications.</p>
<p >To use the alternate <code><a class="el" href="namespaceipc_1_1session_1_1sync__io.html" title="sync_io-pattern counterparts to async-I/O-pattern object types in parent namespace ipc::session.">sync_io</a></code> interface: Look into <a class="el" href="namespaceipc_1_1session_1_1sync__io.html" title="sync_io-pattern counterparts to async-I/O-pattern object types in parent namespace ipc::session.">session::sync_io</a> and its 3 adapter templates:</p><ul>
<li><a class="el" href="classipc_1_1session_1_1sync__io_1_1Server__session__adapter.html" title="sync_io-pattern counterpart to async-I/O-pattern session::Server_session types and all their SHM-awar...">ipc::session::sync_io::Server_session_adapter</a>;</li>
<li><a class="el" href="classipc_1_1session_1_1sync__io_1_1Client__session__adapter.html" title="sync_io-pattern counterpart to async-I/O-pattern session::Client_session types and all their SHM-awar...">ipc::session::sync_io::Client_session_adapter</a>;</li>
<li><a class="el" href="classipc_1_1session_1_1sync__io_1_1Session__server__adapter.html" title="sync_io-pattern counterpart to async-I/O-pattern session::Session_server types and all their SHM-awar...">ipc::session::sync_io::Session_server_adapter</a>.</li>
</ul>
<p >Exactly the aforementioned async APIs are affected. All other APIs are available without change. </p>
</div><h2 class="groupheader">Typedef Documentation</h2>
<a id="a77d8fda00e1e17f595a6a5d4c44375e7" name="a77d8fda00e1e17f595a6a5d4c44375e7"></a>
<h2 class="memtitle"><span class="permalink"><a href="#a77d8fda00e1e17f595a6a5d4c44375e7">&#9670;&nbsp;</a></span>Client_session</h2>

<div class="memitem">
<div class="memproto">
<div class="memtemplate">
template&lt;schema::MqType S_MQ_TYPE_OR_NONE, bool S_TRANSMIT_NATIVE_HANDLES, typename Mdt_payload  = ::capnp::Void&gt; </div>
      <table class="memname">
        <tr>
          <td class="memname">using <a class="el" href="namespaceipc_1_1session.html#a77d8fda00e1e17f595a6a5d4c44375e7">ipc::session::Client_session</a> = typedef <a class="el" href="classipc_1_1session_1_1Client__session__mv.html">Client_session_mv</a>&lt;Client_session_impl&lt;S_MQ_TYPE_OR_NONE, S_TRANSMIT_NATIVE_HANDLES, Mdt_payload&gt; &gt;</td>
        </tr>
      </table>
</div><div class="memdoc">

<p>A vanilla <code>Client_session</code> with no optional capabilities. </p>
<p >See <a class="el" href="classipc_1_1session_1_1Client__session__mv.html" title="Implements Session concept on the Client_app end: a Session_mv that first achieves PEER state by conn...">Client_session_mv</a> (+doc header) for full API as well as its doc header for possible alternatives that add optional capabilities (such as, at least, SHM setup/access). Opposing peer object: <a class="el" href="namespaceipc_1_1session.html#ab01d5bce0ab2f3435ca9dd88d27609dc" title="A vanilla Server_session with no optional capabilities.">Server_session</a>.</p>
<p >The following important template parameters are <em>knobs</em> that control the properties of the session; the opposing <a class="el" href="namespaceipc_1_1session.html#ab01d5bce0ab2f3435ca9dd88d27609dc" title="A vanilla Server_session with no optional capabilities.">Server_session</a> must use identical settings.</p>
<dl class="tparams"><dt>Template Parameters</dt><dd>
  <table class="tparams">
    <tr><td class="paramname">S_MQ_TYPE_OR_NONE</td><td><a class="el" href="classipc_1_1session_1_1Session.html#a2f770785552536f3b929f293c44834d2" title="Each successful open_channel() and on-passive-open handler firing shall yield a concrete transport::C...">Session::Channel_obj</a> (channel openable via <code>open_channel()</code> on this or other side) type config: Enumeration constant that specifies which type of MQ to use (corresponding to all available <a class="el" href="classipc_1_1transport_1_1Persistent__mq__handle.html" title="A documentation-only concept defining the behavior of an object representing a light-weight handle to...">transport::Persistent_mq_handle</a> concept impls) or to not use one (<code>NONE</code>). Note: This <code>enum</code> type is capnp-generated; see common.capnp for values and brief docs. </td></tr>
    <tr><td class="paramname">S_TRANSMIT_NATIVE_HANDLES</td><td><a class="el" href="classipc_1_1session_1_1Session.html#a2f770785552536f3b929f293c44834d2" title="Each successful open_channel() and on-passive-open handler firing shall yield a concrete transport::C...">Session::Channel_obj</a> (channel openable via <code>open_channel()</code> on this or other side) type config: Whether it shall be possible to transmit a native handle via the channel. </td></tr>
    <tr><td class="paramname">Mdt_payload</td><td>See <a class="el" href="classipc_1_1session_1_1Session.html" title="A documentation-only concept defining the local side of an IPC conversation (session) with another en...">Session</a> concept. In addition the same type may be used for <code>mdt</code> or <code>mdt_from_srv_or_null</code> in <code>*_connect()</code>. (If it is used for <code>open_channel()</code> and/or passive-open and/or <code>*connect()</code> <code>mdt</code> and/or <code>mdt_from_srv_or_null</code>, recall that you can use a capnp-<code>union</code> internally for various purposes.)</td></tr>
  </table>
  </dd>
</dl>
<dl class="section see"><dt>See also</dt><dd><a class="el" href="classipc_1_1session_1_1Client__session__mv.html" title="Implements Session concept on the Client_app end: a Session_mv that first achieves PEER state by conn...">Client_session_mv</a> for full API and its documentation. </dd>
<dd>
<a class="el" href="classipc_1_1session_1_1Session.html" title="A documentation-only concept defining the local side of an IPC conversation (session) with another en...">Session</a>: implemented concept. </dd></dl>

</div>
</div>
<a id="ab01d5bce0ab2f3435ca9dd88d27609dc" name="ab01d5bce0ab2f3435ca9dd88d27609dc"></a>
<h2 class="memtitle"><span class="permalink"><a href="#ab01d5bce0ab2f3435ca9dd88d27609dc">&#9670;&nbsp;</a></span>Server_session</h2>

<div class="memitem">
<div class="memproto">
<div class="memtemplate">
template&lt;schema::MqType S_MQ_TYPE_OR_NONE, bool S_TRANSMIT_NATIVE_HANDLES, typename Mdt_payload  = ::capnp::Void&gt; </div>
      <table class="memname">
        <tr>
          <td class="memname">using <a class="el" href="namespaceipc_1_1session.html#ab01d5bce0ab2f3435ca9dd88d27609dc">ipc::session::Server_session</a> = typedef <a class="el" href="classipc_1_1session_1_1Server__session__mv.html">Server_session_mv</a>&lt;Server_session_impl&lt;S_MQ_TYPE_OR_NONE, S_TRANSMIT_NATIVE_HANDLES, Mdt_payload&gt; &gt;</td>
        </tr>
      </table>
</div><div class="memdoc">

<p>A vanilla <code>Server_session</code> with no optional capabilities. </p>
<p >See <a class="el" href="classipc_1_1session_1_1Server__session__mv.html" title="Implements Session concept on the Server_app end: a Session that is emitted in almost-PEER state by l...">Server_session_mv</a> (+doc header) for full API as well as its doc header for possible alternatives that add optional capabilities (such as, at least, SHM setup/access). Opposing peer object: <a class="el" href="namespaceipc_1_1session.html#a77d8fda00e1e17f595a6a5d4c44375e7" title="A vanilla Client_session with no optional capabilities.">Client_session</a>. Emitted by: <a class="el" href="classipc_1_1session_1_1Session__server.html" title="To be instantiated typically once in a given process, an object of this type asynchronously listens f...">Session_server</a>.</p>
<p >The following important template parameters are <em>knobs</em> that control the properties of the session; the opposing <a class="el" href="namespaceipc_1_1session.html#a77d8fda00e1e17f595a6a5d4c44375e7" title="A vanilla Client_session with no optional capabilities.">Client_session</a> must use identical settings.</p>
<dl class="tparams"><dt>Template Parameters</dt><dd>
  <table class="tparams">
    <tr><td class="paramname">S_MQ_TYPE_OR_NONE</td><td>Identical to <a class="el" href="namespaceipc_1_1session.html#a77d8fda00e1e17f595a6a5d4c44375e7" title="A vanilla Client_session with no optional capabilities.">Client_session</a>. </td></tr>
    <tr><td class="paramname">S_TRANSMIT_NATIVE_HANDLES</td><td>Identical to <a class="el" href="namespaceipc_1_1session.html#a77d8fda00e1e17f595a6a5d4c44375e7" title="A vanilla Client_session with no optional capabilities.">Client_session</a>. </td></tr>
    <tr><td class="paramname">Mdt_payload</td><td>See <a class="el" href="classipc_1_1session_1_1Session.html" title="A documentation-only concept defining the local side of an IPC conversation (session) with another en...">Session</a> concept. In addition the same type may be used for <code>mdt_from_cli_or_null</code> (and srv-&gt;cli counterpart) in <a class="el" href="classipc_1_1session_1_1Session__server.html#a13887cd64912bb5f5675e2817ff8435f" title="Asynchronously awaits for an opposing Client_session to request session establishment and calls on_do...">Session_server::async_accept()</a>. (Recall that you can use a capnp-<code>union</code> internally for various purposes.)</td></tr>
  </table>
  </dd>
</dl>
<dl class="section see"><dt>See also</dt><dd><a class="el" href="classipc_1_1session_1_1Server__session__mv.html" title="Implements Session concept on the Server_app end: a Session that is emitted in almost-PEER state by l...">Server_session_mv</a> for full API and its documentation. </dd>
<dd>
<a class="el" href="classipc_1_1session_1_1Session.html" title="A documentation-only concept defining the local side of an IPC conversation (session) with another en...">Session</a>: implemented concept. </dd></dl>

</div>
</div>
<h2 class="groupheader">Function Documentation</h2>
<a id="a0eac87b284d50832334d819a8877cbaa" name="a0eac87b284d50832334d819a8877cbaa"></a>
<h2 class="memtitle"><span class="permalink"><a href="#a0eac87b284d50832334d819a8877cbaa">&#9670;&nbsp;</a></span>ensure_resource_owner_is_app() <span class="overload">[1/2]</span></h2>

<div class="memitem">
<div class="memproto">
      <table class="memname">
        <tr>
          <td class="memname">void ipc::session::ensure_resource_owner_is_app </td>
          <td>(</td>
          <td class="paramtype">flow::log::Logger *&#160;</td>
          <td class="paramname"><em>logger_ptr</em>, </td>
        </tr>
        <tr>
          <td class="paramkey"></td>
          <td></td>
          <td class="paramtype">const fs::path &amp;&#160;</td>
          <td class="paramname"><em>path</em>, </td>
        </tr>
        <tr>
          <td class="paramkey"></td>
          <td></td>
          <td class="paramtype">const <a class="el" href="structipc_1_1session_1_1App.html">App</a> &amp;&#160;</td>
          <td class="paramname"><em>app</em>, </td>
        </tr>
        <tr>
          <td class="paramkey"></td>
          <td></td>
          <td class="paramtype"><a class="el" href="namespaceipc.html#aa3192e586cc45d3e7c22463bf2760f89">Error_code</a> *&#160;</td>
          <td class="paramname"><em>err_code</em> = <code>0</code>&#160;</td>
        </tr>
        <tr>
          <td></td>
          <td>)</td>
          <td></td><td></td>
        </tr>
      </table>
</div><div class="memdoc">

<p>Utility, used internally but exposed in public API in case it is of general use, that checks that the owner of the given resource (at the supplied file system path) is as specified in the given <a class="el" href="structipc_1_1session_1_1App.html" title="A description of an application in this ipc::session inter-process communication universe.">App</a> (<a class="el" href="structipc_1_1session_1_1App.html#a9e32297579603f2d96616976474d0246" title="The application must run as this user ID (UID). Files and other shared resources shall have this owne...">App::m_user_id</a> et al). </p>
<p >If the resource cannot be accessed (not found, permissions...) that system Error_code shall be emitted. If it can, but the owner does not match, <a class="el" href="namespaceipc_1_1session_1_1error.html#a0708d4bec9ae853f4d7e3d7822fc8f2fa5c437fa266aea0c8e2b348ee84dd61fa" title="A resource in the file system (file, SHM pool, MQ, etc.) has or could have unexpected owner; ipc::ses...">error::Code::S_RESOURCE_OWNER_UNEXPECTED</a> shall be emitted.</p>
<dl class="params"><dt>Parameters</dt><dd>
  <table class="params">
    <tr><td class="paramname">logger_ptr</td><td>Logger to use for logging (WARNING, on error only, including <code>S_RESOURCE_OWNER_UNEXPECTED</code>). </td></tr>
    <tr><td class="paramname">path</td><td>Path to resource. Symlinks are followed, and the target is the resource in question (not the symlink). </td></tr>
    <tr><td class="paramname">app</td><td>Describes the app with the expected owner info prescribed therein. </td></tr>
    <tr><td class="paramname">err_code</td><td>See <code>flow::Error_code</code> docs for error reporting semantics. <a class="el" href="namespaceipc.html#aa3192e586cc45d3e7c22463bf2760f89" title="Short-hand for flow::Error_code which is very common.">Error_code</a> generated: <a class="el" href="namespaceipc_1_1session_1_1error.html#a0708d4bec9ae853f4d7e3d7822fc8f2fa5c437fa266aea0c8e2b348ee84dd61fa" title="A resource in the file system (file, SHM pool, MQ, etc.) has or could have unexpected owner; ipc::ses...">error::Code::S_RESOURCE_OWNER_UNEXPECTED</a> (check did not pass), system error codes if ownership cannot be checked. </td></tr>
  </table>
  </dd>
</dl>

</div>
</div>
<a id="ac7f0052fa0537c3696063693644bcff8" name="ac7f0052fa0537c3696063693644bcff8"></a>
<h2 class="memtitle"><span class="permalink"><a href="#ac7f0052fa0537c3696063693644bcff8">&#9670;&nbsp;</a></span>ensure_resource_owner_is_app() <span class="overload">[2/2]</span></h2>

<div class="memitem">
<div class="memproto">
      <table class="memname">
        <tr>
          <td class="memname">void ipc::session::ensure_resource_owner_is_app </td>
          <td>(</td>
          <td class="paramtype">flow::log::Logger *&#160;</td>
          <td class="paramname"><em>logger_ptr</em>, </td>
        </tr>
        <tr>
          <td class="paramkey"></td>
          <td></td>
          <td class="paramtype"><a class="el" href="structipc_1_1util_1_1Native__handle.html">util::Native_handle</a>&#160;</td>
          <td class="paramname"><em>handle</em>, </td>
        </tr>
        <tr>
          <td class="paramkey"></td>
          <td></td>
          <td class="paramtype">const <a class="el" href="structipc_1_1session_1_1App.html">App</a> &amp;&#160;</td>
          <td class="paramname"><em>app</em>, </td>
        </tr>
        <tr>
          <td class="paramkey"></td>
          <td></td>
          <td class="paramtype"><a class="el" href="namespaceipc.html#aa3192e586cc45d3e7c22463bf2760f89">Error_code</a> *&#160;</td>
          <td class="paramname"><em>err_code</em> = <code>0</code>&#160;</td>
        </tr>
        <tr>
          <td></td>
          <td>)</td>
          <td></td><td></td>
        </tr>
      </table>
</div><div class="memdoc">

<p>Identical to the other <a class="el" href="namespaceipc_1_1session.html#a0eac87b284d50832334d819a8877cbaa" title="Utility, used internally but exposed in public API in case it is of general use, that checks that the...">ensure_resource_owner_is_app()</a> overload but operates on a pre-opened <code>Native_handle</code> (a/k/a handle, socket, file descriptor) to the resource in question. </p>
<dl class="params"><dt>Parameters</dt><dd>
  <table class="params">
    <tr><td class="paramname">logger_ptr</td><td>See other overload. </td></tr>
    <tr><td class="paramname">handle</td><td>See above. <code>handle.null() == true</code> causes undefined behavior (assertion may trip). Closed/invalid/etc. handle will yield civilized Error_code emission. </td></tr>
    <tr><td class="paramname">app</td><td>See other overload. </td></tr>
    <tr><td class="paramname">err_code</td><td>See <code>flow::Error_code</code> docs for error reporting semantics. <a class="el" href="namespaceipc.html#aa3192e586cc45d3e7c22463bf2760f89" title="Short-hand for flow::Error_code which is very common.">Error_code</a> generated: <a class="el" href="namespaceipc_1_1session_1_1error.html#a0708d4bec9ae853f4d7e3d7822fc8f2fa5c437fa266aea0c8e2b348ee84dd61fa" title="A resource in the file system (file, SHM pool, MQ, etc.) has or could have unexpected owner; ipc::ses...">error::Code::S_RESOURCE_OWNER_UNEXPECTED</a> (check did not pass), system error codes if ownership cannot be checked (invalid descriptor, un-opened descriptor, etc.). </td></tr>
  </table>
  </dd>
</dl>

</div>
</div>
<a id="a6b2f9a90ac9cc5098d9b90e7f547c97e" name="a6b2f9a90ac9cc5098d9b90e7f547c97e"></a>
<h2 class="memtitle"><span class="permalink"><a href="#a6b2f9a90ac9cc5098d9b90e7f547c97e">&#9670;&nbsp;</a></span>operator&lt;&lt;() <span class="overload">[1/7]</span></h2>

<div class="memitem">
<div class="memproto">
      <table class="memname">
        <tr>
          <td class="memname">std::ostream &amp; operator&lt;&lt; </td>
          <td>(</td>
          <td class="paramtype">std::ostream &amp;&#160;</td>
          <td class="paramname"><em>os</em>, </td>
        </tr>
        <tr>
          <td class="paramkey"></td>
          <td></td>
          <td class="paramtype">const <a class="el" href="structipc_1_1session_1_1App.html">App</a> &amp;&#160;</td>
          <td class="paramname"><em>val</em>&#160;</td>
        </tr>
        <tr>
          <td></td>
          <td>)</td>
          <td></td><td></td>
        </tr>
      </table>
</div><div class="memdoc">

<p>Prints string representation of the given <code><a class="el" href="structipc_1_1session_1_1App.html" title="A description of an application in this ipc::session inter-process communication universe.">App</a></code> to the given <code>ostream</code>. </p>
<dl class="params"><dt>Parameters</dt><dd>
  <table class="params">
    <tr><td class="paramname">os</td><td>Stream to which to write. </td></tr>
    <tr><td class="paramname">val</td><td>Object to serialize. </td></tr>
  </table>
  </dd>
</dl>
<dl class="section return"><dt>Returns</dt><dd><code>os</code>. </dd></dl>

</div>
</div>
<a id="a0e786447d51449f1249c10e127ab10e2" name="a0e786447d51449f1249c10e127ab10e2"></a>
<h2 class="memtitle"><span class="permalink"><a href="#a0e786447d51449f1249c10e127ab10e2">&#9670;&nbsp;</a></span>operator&lt;&lt;() <span class="overload">[2/7]</span></h2>

<div class="memitem">
<div class="memproto">
      <table class="memname">
        <tr>
          <td class="memname">std::ostream &amp; operator&lt;&lt; </td>
          <td>(</td>
          <td class="paramtype">std::ostream &amp;&#160;</td>
          <td class="paramname"><em>os</em>, </td>
        </tr>
        <tr>
          <td class="paramkey"></td>
          <td></td>
          <td class="paramtype">const <a class="el" href="structipc_1_1session_1_1Client__app.html">Client_app</a> &amp;&#160;</td>
          <td class="paramname"><em>val</em>&#160;</td>
        </tr>
        <tr>
          <td></td>
          <td>)</td>
          <td></td><td></td>
        </tr>
      </table>
</div><div class="memdoc">

<p>Prints string representation of the given <code>Client_appp</code> to the given <code>ostream</code>. </p>
<dl class="params"><dt>Parameters</dt><dd>
  <table class="params">
    <tr><td class="paramname">os</td><td>Stream to which to write. </td></tr>
    <tr><td class="paramname">val</td><td>Object to serialize. </td></tr>
  </table>
  </dd>
</dl>
<dl class="section return"><dt>Returns</dt><dd><code>os</code>. </dd></dl>

</div>
</div>
<a id="a8a2e780e6c5266b8c2e4207d7e256afe" name="a8a2e780e6c5266b8c2e4207d7e256afe"></a>
<h2 class="memtitle"><span class="permalink"><a href="#a8a2e780e6c5266b8c2e4207d7e256afe">&#9670;&nbsp;</a></span>operator&lt;&lt;() <span class="overload">[3/7]</span></h2>

<div class="memitem">
<div class="memproto">
<div class="memtemplate">
template&lt;typename Client_session_impl_t &gt; </div>
      <table class="memname">
        <tr>
          <td class="memname">std::ostream &amp; operator&lt;&lt; </td>
          <td>(</td>
          <td class="paramtype">std::ostream &amp;&#160;</td>
          <td class="paramname"><em>os</em>, </td>
        </tr>
        <tr>
          <td class="paramkey"></td>
          <td></td>
          <td class="paramtype">const <a class="el" href="classipc_1_1session_1_1Client__session__mv.html">Client_session_mv</a>&lt; Client_session_impl_t &gt; &amp;&#160;</td>
          <td class="paramname"><em>val</em>&#160;</td>
        </tr>
        <tr>
          <td></td>
          <td>)</td>
          <td></td><td></td>
        </tr>
      </table>
</div><div class="memdoc">

<p>Prints string representation of the given <code><a class="el" href="classipc_1_1session_1_1Client__session__mv.html" title="Implements Session concept on the Client_app end: a Session_mv that first achieves PEER state by conn...">Client_session_mv</a></code> to the given <code>ostream</code>. </p>
<dl class="params"><dt>Parameters</dt><dd>
  <table class="params">
    <tr><td class="paramname">os</td><td>Stream to which to write. </td></tr>
    <tr><td class="paramname">val</td><td>Object to serialize. </td></tr>
  </table>
  </dd>
</dl>
<dl class="section return"><dt>Returns</dt><dd><code>os</code>. </dd></dl>

</div>
</div>
<a id="a34a03a25908100446b3eca2e8dca61fe" name="a34a03a25908100446b3eca2e8dca61fe"></a>
<h2 class="memtitle"><span class="permalink"><a href="#a34a03a25908100446b3eca2e8dca61fe">&#9670;&nbsp;</a></span>operator&lt;&lt;() <span class="overload">[4/7]</span></h2>

<div class="memitem">
<div class="memproto">
      <table class="memname">
        <tr>
          <td class="memname">std::ostream &amp; operator&lt;&lt; </td>
          <td>(</td>
          <td class="paramtype">std::ostream &amp;&#160;</td>
          <td class="paramname"><em>os</em>, </td>
        </tr>
        <tr>
          <td class="paramkey"></td>
          <td></td>
          <td class="paramtype">const <a class="el" href="structipc_1_1session_1_1Server__app.html">Server_app</a> &amp;&#160;</td>
          <td class="paramname"><em>val</em>&#160;</td>
        </tr>
        <tr>
          <td></td>
          <td>)</td>
          <td></td><td></td>
        </tr>
      </table>
</div><div class="memdoc">

<p>Prints string representation of the given <code><a class="el" href="structipc_1_1session_1_1Server__app.html" title="An App that is used as a server in at least one client-server IPC split.">Server_app</a></code> to the given <code>ostream</code>. </p>
<dl class="params"><dt>Parameters</dt><dd>
  <table class="params">
    <tr><td class="paramname">os</td><td>Stream to which to write. </td></tr>
    <tr><td class="paramname">val</td><td>Object to serialize. </td></tr>
  </table>
  </dd>
</dl>
<dl class="section return"><dt>Returns</dt><dd><code>os</code>. </dd></dl>

</div>
</div>
<a id="aed5397fd025606507ad8dab74479762f" name="aed5397fd025606507ad8dab74479762f"></a>
<h2 class="memtitle"><span class="permalink"><a href="#aed5397fd025606507ad8dab74479762f">&#9670;&nbsp;</a></span>operator&lt;&lt;() <span class="overload">[5/7]</span></h2>

<div class="memitem">
<div class="memproto">
<div class="memtemplate">
template&lt;typename Server_session_impl_t &gt; </div>
      <table class="memname">
        <tr>
          <td class="memname">std::ostream &amp; operator&lt;&lt; </td>
          <td>(</td>
          <td class="paramtype">std::ostream &amp;&#160;</td>
          <td class="paramname"><em>os</em>, </td>
        </tr>
        <tr>
          <td class="paramkey"></td>
          <td></td>
          <td class="paramtype">const <a class="el" href="classipc_1_1session_1_1Server__session__mv.html">Server_session_mv</a>&lt; Server_session_impl_t &gt; &amp;&#160;</td>
          <td class="paramname"><em>val</em>&#160;</td>
        </tr>
        <tr>
          <td></td>
          <td>)</td>
          <td></td><td></td>
        </tr>
      </table>
</div><div class="memdoc">

<p>Prints string representation of the given <code><a class="el" href="classipc_1_1session_1_1Server__session__mv.html" title="Implements Session concept on the Server_app end: a Session that is emitted in almost-PEER state by l...">Server_session_mv</a></code> to the given <code>ostream</code>. </p>
<dl class="params"><dt>Parameters</dt><dd>
  <table class="params">
    <tr><td class="paramname">os</td><td>Stream to which to write. </td></tr>
    <tr><td class="paramname">val</td><td>Object to serialize. </td></tr>
  </table>
  </dd>
</dl>
<dl class="section return"><dt>Returns</dt><dd><code>os</code>. </dd></dl>

</div>
</div>
<a id="a07c2d7a228f070e32bf4f1fbc64e1f6d" name="a07c2d7a228f070e32bf4f1fbc64e1f6d"></a>
<h2 class="memtitle"><span class="permalink"><a href="#a07c2d7a228f070e32bf4f1fbc64e1f6d">&#9670;&nbsp;</a></span>operator&lt;&lt;() <span class="overload">[6/7]</span></h2>

<div class="memitem">
<div class="memproto">
<div class="memtemplate">
template&lt;typename Session_impl_t &gt; </div>
      <table class="memname">
        <tr>
          <td class="memname">std::ostream &amp; operator&lt;&lt; </td>
          <td>(</td>
          <td class="paramtype">std::ostream &amp;&#160;</td>
          <td class="paramname"><em>os</em>, </td>
        </tr>
        <tr>
          <td class="paramkey"></td>
          <td></td>
          <td class="paramtype">const <a class="el" href="classipc_1_1session_1_1Session__mv.html">Session_mv</a>&lt; Session_impl_t &gt; &amp;&#160;</td>
          <td class="paramname"><em>val</em>&#160;</td>
        </tr>
        <tr>
          <td></td>
          <td>)</td>
          <td></td><td></td>
        </tr>
      </table>
</div><div class="memdoc">

<p>Prints string representation of the given <code><a class="el" href="classipc_1_1session_1_1Session__mv.html" title="Implements the Session concept when it is in PEER state.">Session_mv</a></code> to the given <code>ostream</code>. </p>
<dl class="params"><dt>Parameters</dt><dd>
  <table class="params">
    <tr><td class="paramname">os</td><td>Stream to which to write. </td></tr>
    <tr><td class="paramname">val</td><td>Object to serialize. </td></tr>
  </table>
  </dd>
</dl>
<dl class="section return"><dt>Returns</dt><dd><code>os</code>. </dd></dl>

</div>
</div>
<a id="addd131b7a844d2a22a7436ed0c8597bc" name="addd131b7a844d2a22a7436ed0c8597bc"></a>
<h2 class="memtitle"><span class="permalink"><a href="#addd131b7a844d2a22a7436ed0c8597bc">&#9670;&nbsp;</a></span>operator&lt;&lt;() <span class="overload">[7/7]</span></h2>

<div class="memitem">
<div class="memproto">
<div class="memtemplate">
template&lt;schema::MqType S_MQ_TYPE_OR_NONE, bool S_TRANSMIT_NATIVE_HANDLES, typename Mdt_payload &gt; </div>
      <table class="memname">
        <tr>
          <td class="memname">std::ostream &amp; ipc::session::operator&lt;&lt; </td>
          <td>(</td>
          <td class="paramtype">std::ostream &amp;&#160;</td>
          <td class="paramname"><em>os</em>, </td>
        </tr>
        <tr>
          <td class="paramkey"></td>
          <td></td>
          <td class="paramtype">const <a class="el" href="classipc_1_1session_1_1Session__server.html">Session_server</a>&lt; S_MQ_TYPE_OR_NONE, S_TRANSMIT_NATIVE_HANDLES, Mdt_payload &gt; &amp;&#160;</td>
          <td class="paramname"><em>val</em>&#160;</td>
        </tr>
        <tr>
          <td></td>
          <td>)</td>
          <td></td><td></td>
        </tr>
      </table>
</div><div class="memdoc">

<p>Prints string representation of the given <code><a class="el" href="classipc_1_1session_1_1Session__server.html" title="To be instantiated typically once in a given process, an object of this type asynchronously listens f...">Session_server</a></code> to the given <code>ostream</code>. </p>
<dl class="params"><dt>Parameters</dt><dd>
  <table class="params">
    <tr><td class="paramname">os</td><td>Stream to which to write. </td></tr>
    <tr><td class="paramname">val</td><td>Object to serialize. </td></tr>
  </table>
  </dd>
</dl>
<dl class="section return"><dt>Returns</dt><dd><code>os</code>. </dd></dl>

</div>
</div>
</div><!-- contents -->
<!-- start footer part -->
<hr class="footer"/><address class="footer"><small>
Generated on Fri Apr 11 2025 20:02:23 for Flow-IPC by&#160;<a href="https://www.doxygen.org/index.html"><img class="footer" src="doxygen.svg" width="104" height="31" alt="doxygen"/></a> 1.9.4
</small></address>
</body>
</html>
